In present-day video games, as in televised sports, a popular feature is “instant replay.” This feature allows a play or event that has just occurred live to be re-shown to the player(s) or to an audience.
For the case of televised sports, the video signal from each of the cameras covering the action is recorded and perhaps compressed. To achieve an instant replay, one or more of those recordings is replayed. If a different camera is selected for playback than was originally selected, then the audience is able to experience the same play or event from a different viewpoint. In some sports, the judges or referees present at the live event may use “instant replay” technology, but as a way of reviewing the play or event from a vantage other than their own experience of the game.
In video games, the technology is different. Recording video is a computationally heavy burden that is often not even supported by a game console's hardware, where the rendering of audio and video graphics is performed by dedicated chips whose outputs may not be accessible to a main processor for capture. Further, it is commonly the nature of video games to make maximum use of the computational resources, so little excess capability is left unused. Thus, even when possible, capture of video for later playback, even from the original game player's point of view, would severely limit the other features of the game, for example graphics complexity, number of players, number of game objects, etc.
To overcome this limitation, many modern games will instead capture a “game file.” A “game file” contains data representative of the game state at one or more points (for example, the initial state at the beginning of the game, or a checkpoint at some intermediate state during play), and timestamped or periodic data necessary to reproduce the original sequence of events in the game. Such timestamped or periodic data might represent, for example, game controller button presses. This requires the game to be substantially deterministic: Starting from a specific state, with specific input events applied at specific times, the game outcome will be either exactly or substantially the same.
In a single player game, the only events that can affect a deterministic game are those input by the player. Such input events may include simple controller inputs, such as button presses and releases, or periodic joystick readings or joystick position updates. Input events may also come as the results of processing more complex control inputs. For example, a complex control input may be the analysis of video from a camera watching the player: When the video of the player's motions is analyzed, the system may recognize a predetermined gesture (e.g., a wave) or a value (e.g., angle at which the player's body is leaning), which produces an input event. Another example of a complex control input is an audio input from a microphone monitoring a player's voice: Application of a speech recognition algorithm can recognize spoken commands or the level of stress in the player's voice, where a recognized command or stress value becomes an input event.
In a multi-player game, the input events produced by each of the players can be recorded. When players all have separate controllers on the same console, this is common. However, in a distributed multi-player game, where different players have separate consoles connected through a communications channel (e.g., infrared link, Bluetooth (™), wired or wireless local area network, telephone network or the Internet), it can be sufficient to record only the messages sent among consoles. In some distributed multi-player games, the input events from each player are processed by the corresponding console, and those input events result in changes to the state of in-game objects, which are then shared. Such an implementation choice may be made because data representing the changes to in-game objects is smaller than the data representing the input events, or because processing the input events from all the players is too great a burden. For example, when a joystick input is used for aiming, determining the currently selected target may be an expensive computation, so rather than exchange the current joystick value and require all participating consoles to compute the currently selected target, the console to which the joystick is attached may determine the target and send the target's identity to the other consoles. To send raw input events versus preprocessed object updates is an implementation decision, and may vary even within a game application (i.e., objects updates are sent in some cases, and raw input events are sent in others).
Thus, the timestamped data to be recorded in a game file can represent either input events from players, or the messages received by a console from the other game participants, or a mix thereof. A game file of this kind is used, for example, in Halo 3 (™), published by Microsoft, Inc, of Redmond, Wash., beginning in September of 2007.
Given such a “game file,” an instant replay can be achieved on a similar console running the same game program. The game state, as recorded in the game file, is used to recreate the game state on the console as it happened in the original play. Then, the timestamped data is supplied to the game engine, in lieu of actual input from player controls or other consoles. This can occur in real-time, in which case the playback audio and video is similar to if not identically what the player originally saw, or the game console can playback using a slowed-down clock, in which case the playback can be in slow motion.
Generally, game files cannot be played backwards, because the nature of the game model cannot be run in reverse. In some implementations, to support a rewind capability, game files include intermediate checkpoints. Each intermediate checkpoint includes a game state, similar to that of the initial state, from which playback of the game file can be started. With intermediate checkpoints, a rewind facility can be provided to allow a player to replay a piece of the action repeatedly, without having to always start over at the beginning of the game file. In Halo 3 (™) (op. cit.), intermediate checkpoints are included in the game file every few seconds. Thus, when reviewing the record of a game, a user can skip forward or backwards to any point in the file, with a temporal resolution of a few seconds.
In some implementations, notably that of Halo 3 (™), during playback of a game file, the user has the option of altering the camera position to be different from that which the original player experienced. For example, the original player may have been playing with the camera set to the first-person point-of-view (POV) of the player's character, that is, the game was seen through the eyes of the player's own character.
However, upon playback, the camera can be switched to watch the action from another character's POV, or from behind the player's character. In some implementations, the camera can fly over the action—either tethered to a character, or constrained to point toward a character, or both, or neither: free to fly and point anywhere.
Only minor edits to a game file are appropriate. For example, an override of the original camera position can be recorded during a playback and incorporated into an edited game file. It is up to the implementation to determine whether this override replaces the camera position as originally recorded, or whether the override is distinct from the original camera position, such that a “use original camera position” option can be presented in case the user later decides that a portion of the original camera position record was preferred to the edited version.
With a sound or video recording, an editor has the ability to specify an “in-point” and “out-point” within the recording to identify a particular segment of the recording that is desired for playback or copying. Similarly, an in- and/or out-point may be specified for a game file. This allows a user having a complete game file, which might run for fifteen minutes, to identify a portion of interest. Thus, if a spectacular thirty-second event, worthy of sharing, occurred at seven minutes and two seconds into a fifteen-minute game file, an in- and out-point could be specified that directs playback of the edited clip to show substantially only the selected interesting part. Thus, by setting the in- and out-points, the interval of live game play represented by the game file may be an entire session, or a specific interval of interest.
In some implementations, including Halo 3 (™), edited game files may be made smaller than the original file by dropping any game states and events from the start of the game file up to (but not including) the intermediate checkpoint at or immediately prior to the specified in-point. If there is no intermediate game state prior to the in-point, or no in-point is set, then the start of the file is not clipped in this way. The edited game file may also be shortened by dropping all events and intermediate game states that occur after the out-point, if any. In the prior example, the fifteen-minute game file could be saved as an edited game file that was only about thirty seconds long (or slightly longer as will be discussed below).
In some implementations that allow an in-point to be specified as a time or frame number having a precision greater than that of the corresponding prior game state (whether the initial game state, or an intermediate checkpoint), the game console begins playback at the game state immediately prior to the in-point specified, but keeps video blanked and audio muted until the in-point is reached. For this reason, if a game were to save intermediate checkpoints every five seconds, then the edited game file in the example above would contain thirty to thirty-five seconds worth of data, even if the in- and out-points selected were thirty seconds apart.
Thus an edited game file may be saved as a “clipped game file,” and contain only the intermediate game states that are both immediately prior to the in-point and prior to the out-point, and the game events that are between that first retained game state up to those at the out-point. However, in all respects, a clipped game file is still a game file, and may be treated in the same way, including subsequent editing. Upon playback, the resulting clipped game file still resembles an ordinary game file, but the playback can begin in medias res (in the middle of the action). The reduced size takes up less storage and is easier and less expensive to share, since upload and download times are reduced.
The ability to alter the camera's vantage during playback of a game file provides a sophisticated instant replay mechanism, allowing a player to review his own play, to determine why a particular strategy succeeded or failed. The addition of setting in- and out-points to quickly get to the interesting action (which may or may not include clipping game files) provides a good way to show the performance to others, either to be instructive, or entertaining.
There is a drawback to game files, however, namely that in order for them to be viewed, a user must have an appropriate game console and a copy of the game. This is fine for players who are using game files for instant replay, or who are sharing game files with other players who already own the game, but severely limits the audience for what may otherwise be an enjoyable form of entertainment.